      *      *                   *     *                          *
      **     *                   **   **                          *
      * *    *             *     * * * *          *          *    *
      *  *   *   *****  *******  *  *  *   *****  ******  ******* ******
      *   *  *  *     *    *     *     *  *     * *     *    *    *     *
      *    * *  *******    *     *     *  *     * *     *    *    *     *
      *     **  *          *     *     *  *     * *     *    *    *     *
      *      *   ******    *     *     *   *****  *     *    *    *     *
      *                                                                 *
      *             The guide to BITNET servers and services            *
      *                                                                 *
      *  Volume 2  Number 2                                August 1987  *
      *                                                                 *
       *****************************************************************
      *                                                                 *
      *  Editor:                           Chris Condon  CONDON@YALEVM  *
      *  Assistant Editor:                 Steve Sutter  SUTTER@YALEVM  *
      *  NetMonth Staff Supervisor:        Gary Moss       MOSS@YALEVM  *
      *                                                                 *
       *****************************************************************
      *    *        *     *     *       *       *             *       * *
      *     *        *     *   *       *       *               *     *  *
      *      *        *     * *       *       *                 *   *   *
      *       *        *     *********       * *                 * *    *
      *        *        *   * *       *     *   *                 *     *
      *         *        * *   *       *   *     *                 *    *
      **         **********     *       * *       *                 *   *
      * *       *        *       *********         *                 *  *
      *  *     *        *       *     * *           *                 * *
      *   *   *        *       *       *             *                 **
      *    * *        *       *       * *             *******************
      ****** *********       *       *   *           *                 **
      *     **        *     *       *     *         *                 * *
      *     * *        *   *       *       *       *                 *  *
      *     *  *        * *       ***********     *                 *  **
      *******   *        **      *          *    *                 *  * *
      *      *   **********     *           *   *       *         *  *  *
      *       *  *        *    *            *  *       * *       ****   *
      *        * *        *   *             * *       *   *     *    *  *
      * *       **        *  *              *        *     *   *      * *
      *  *       *        * *               *       *       * *        **
      *   ***************** *****************      *         ************
      *  *               **             *  *      *         *          **
      * *               * *             * *      *         *          * *
      **               *  *             **      *         *          *  *
      *****************   *             *      *         *          *   *
      *               *   *             *     *         *          *    *
      *               *   *             *****          ************     *
      *               *   ***************    *        * *          *    *
      *               *  *             *      *      *   *          *   *
      *               * *             *        *    *     *          *  *
      *               **             *          *  *       *          * *
      *               *             *            **         *          **
       *****************************************************************
1


   *************************************************************************
  * Contents                                                                *
  ***************************************************************************

  Bitnotes ................................................................ 1

  TAKE NOTE__________________________________________________________________

  Scuttlebut .............................................................. 4
  BITNET User Statistics .................................................. 7

  FEATURES___________________________________________________________________

  The Best of the Big Flamage ............................................. 8
  Commentary on WISCVM ................................................... 13

  SERVERS AND SERVICES_______________________________________________________

  The Poetry Server: BIALIK@BRANDEIS ..................................... 17
  A New Name Server: WHOIS@UKCC .......................................... 18

  DEPARTMENTS________________________________________________________________

  Feedback ............................................................... 19
  Policies ............................................................... 22

  NetMonth is a  network service  publication  distributed free  of charge to
  students and professionals in BITNET and other networks.  This magazine and
  it's  companion  file, BITNET SERVERS, are  the work  of the  Yale Computer
  Center  BITNET  Services  Library  (BITLIB) staff.  The  BITLIB  is a local
  online help  facility designed to  inform  Yale network  users  about  what
  services are available  to them  through BITNET, and  provide  instructions
  and  utilities  for their  proper use.  In publishing  NetMonth  the BITLIB
  staff  members hope  to share the  fruits of their  labor with institutions
  outside of Yale in  order to promote a productive  and enjoyable networking
  environment for everyone. The BITLIB system is now distributed to more than
  thirty educational institutions worldwide.

  BITNET SERVERS is BITNET's most  complete  and  up-to-date  list of servers
  and services.  It is sent to  NetMonth  subscribers at the same time as the
  magazine.  BITNET SERVERS is dependent  on your support to remain accurate.
  If you know of servers and  services  not  listed  in BITNET SERVERS, or of
  those listed in the file that  are no longer available, please  contact the
  NetMonth staff at BITLIB@YALEVMX.

  For information  on  subscribing  to NetMonth  and  BITNET SERVERS, see the
  "Policies" section on the last pages of this issue. Within "Policies" there
  are also instructions for  submitting  articles,  sending  Letters  to  the
  Editor, and printing this file.

  -----------------------------------------------------

  A publication of the Bitnet Services Library          "Because We're Here."
1

                                                                       Page 1


   *************************************************************************
  * Bitnotes                                                       Issue 13 *
  ***************************************************************************


      "We  trained  very hard,  but it  seemed  that  every time we were
       beginning to form up into teams, we would  be reorganised.  I was
       to learn later in life that we tend to meet  any new situation by
       reorganising, and what a wonderful  method it can be for creating
       the illusion of progress while producing confusion, inefficiency,
       and demoralisation."
                               -  Caius Petronius (A.D. 66)


  As usual, I found myself in something  of a pickle.   No, it was  not large
  and green,  nor  was  it a  kosher  dill.  It was the  sort of pickle I get
  myself into when I have to take a stand on an issue.

  "Oh, horror!"  I said, dripping with  sarcasm. "I have to make some kind of
  decision...  What shall I do, what shall I do?"

  It was not a pretty sight.   Not only was the confused look on my face less
  less than attractive,  but  the sarcasm was leaving a slimy  green trace on
  the floor.  Another mess to be dealt with, but that would have to wait.   A
  more pressing situation had presented  itself;  this was the reason for the
  current pickle:

  The position of  Editor for this illustrious publication  and the editorial
  writing that goes along with it put me in very public position (for BITNET,
  that is).   As such  I generally end up making some sort  of comment on the
  latest crisis, whatever it may be.  In most cases it is rather easy to form
  an opinion on a particular subject:  Network load is Bad;  Relays are Good.
  Sometimes, however, the problem involves the Network Information Center, or
  BITNIC as it is  usually called.   Now the problem (or  pickle)  comes to a
  head.

  This, you see,  brings me into the realm of politics,  a dangerous area for
  someone in a position where it is best to appear neutral.  Still, I do have
  to write an editorial about SOMETHING,  and it would seem sort of silly for
  me to comment on the weather while there is a battle raging about Issue X.

  Now,  I don't have  much of a problem with forming  an opinion on anything,
  but here I end up in a tight spot:   If my opinion leans in one direction I
  could be accused of  acting anti-BITNIC and extremist,  and much  of what I
  say could and would be discounted as so  much hot air.   On the other hand,
  were I to lean in the other direction I might be thought of as being simply
  part of the establishment worthy of being ignored.

  Obviously, I worry too much, but it is sometimes difficult to even consider
1

                                                                       Page 2


  putting our image and that for which we  have worked at risk.   I have seen
  it happen to the BITNIC, and it looks very painful.

  What's worse,  with  the way I think,   I stand a good  chance of offending
  everybody on each side of the political  extreme.   On yet a third hand,  I
  don't care WHAT everybody thinks,  because I tend to think I am right until
  proven otherwise.  Not that I am one to become indignant.   Not me.  (Gosh,
  that sarcasm sure is hard to clean up!)

  So be it.   Here is the problem (finally!)   Damn the torpedos,  full speed
  ahead!

  The problem was apparently caused by this announcement, from the June, 1987
  Bitnews:


       To Serve You More Efficiently

       In a continuing effort to  make NICSERVE@BITNIC more responsive to
       user needs and  to provide better BITNET user  services,  the most
       frequently requested files,   which are also some  of the largest,
       are being moved to LISTSERV@BITNIC.

       In the  past,  the NAMES  files were automatically  distributed to
       designated userids at all BITNET nodes, as well as being generally
       available  through  NICSERVE@BITNIC.   The  dramatic  increase  of
       BITNET nodes  and users made  the automatic distribution  of these
       files a  time-consuming as well network-clogging  activity.   With
       the efficient file-distribution capabilities  of the LISTSERV file
       servers, we can again make the NAMES files automatically available
       to those who want them.

       You  can  subscribe  to  these   files  and  either  receive  them
       automatically through overnight shipments or  elect to be notified
       of file updates.  As was true with NICSERVE, you can still request
       the files for immediate delivery from LISTSERV, if necessary.   In
       keeping with our goal to reduce  network traffic,  we ask that you
       contact your BITNET Technical Services Representative to determine
       whether  a copy  of  the file  is available  at  your node  before
       subscribing yourself to the list.

       Our plans  for future efficiency  improvements include  making the
       NAMES   files   available   only  from   your   BITNET   Technical
       Representative.   Sending  only 1  copy of  each NAMES  file to  a
       member site will greatly assist in reducing network traffic.   All
       subscribers  will be  notified of  the impending  change,  and  an
       announcement will also appear in BITNEWS.

       (various technical notes followed)
1

                                                                      Page 3


  Now the  kicker:    I am  not overly informed  about the technical  matters
  of running the network.    I post  the more  interesting notes from Bitnews
  in the Scuttlebut column,    and I  saw the notice the  BITNIC had  posted.
  I read it over,   their explanation for their action seemed  lucid,   but I
  didn't think it was important enough for these pages.

  So much  for my  judgement.   Or  maybe not.   It  still seems  that it  is
  a technical matter that  can be solved with a little  sweat.   Now that the
  BITNIC knows that their move has caused some problems,  one might hope that
  they will address  the issue.    One does not expect,   however,   that the
  network at large would engage in a  flaming-frenzy every time  a mistake is
  made.   They BITNIC staff has made some mistakes.  They will make more.   I
  have noticed, however,  that people tend to learn from their mistakes.   In
  any job  I have  had,  I have  made every   single mistake   possible  (and
  thought up  some new ones)  before settling in and doing  the usual bang-up
  job.   The trick is  try not to make the same mistake twice.

  So who is to  blame,  really?    The notice of the NAMES  change was posted
  on June  2nd.    The Big Flamage  didn't begin until early  August.    What
  happened?   Well,   one person who brought the action to our attention said
  something like this:    "I  felt that it was so stupid  that I didn't think
  they would actually do it, so I waited until after they made the change."

  Oh,   come now.    How  can the BITNIC be  responsive to  your needs if you
  don't tell them what  your needs are?   By posting  a notice a month  ahead
  of time they essentially said,   "Hey,   we want to do  this.    Tell us if
  you have a problem with it before it's too late."

  The Network Information  Center  cannot and will not be  effective  if they
  are called  a bunch of  "sales people" every  time they,  well,   screw up.
  They were  chosen  to run  the  network  by the  Executive   Committee (now
  the Board  of Trustees) the members of which were elected by the people who
  run your nodes.  As such,  they HAVE to be given a  chance to do their job.
  Anything less is unfair to them and to the network at large.

  I am not  saying that the BITNIC  should not be criticized.     Rather,  we
  should concentrate  on  the problem  at  hand  and work  together  to solve
  them rather  than question the  abilities of  the people  who  caused them.
  They will learn from their mistakes, and the network will be a better place
  for it.


  Virtually,

    Chris Condon@YALEVM

  See in this issue:  Best of the Big Flamage

1

                                                                       Page 4


   *************************************************************************
  * Scuttlebut                                                              *
  ***************************************************************************

  * More list servers, and the parties responsible for telling me about them:

           LISTSERV @ UAVM1        Craig White, Rocky Waters
           LISTSERV @ BROWNVM      Peter DiCamillo
           LISTSERV @ UBVM         Rocky Waters
           LISTSERV @ HEARN        Peter Barneveld
           LISTSERV @ RPICICGE     Peter Barneveld


  * WISCVM woes:  (See also the article concerning the WISCVM shutdown).

  On December 1, WISCVM will be shut down.   Hence, as of that date,  we will
  no longer  be able  to provide  a mail  relay service  between Arpanet  and
  BITNET.

  WISCVM  currently handles  between  5 and  10  thousand  messages per  day.
  Clearly,  this service  is very important to  the academic/research network
  community.  As such it  should be fully supported.  Many of  you may not be
  aware that  at present the  WISCVM relay is  only supported by  a volunteer
  student (indeed,  this summer he has a full-time job off campus).   Because
  of  the  (admittedly)    inadequate  level  of  support,    problems  arise
  periodically.   For example,   for the  past  day most  messages have  been
  rejected.  The current problem occurred because there was some ambiguity in
  our instructions for installing new host tables.

  We would be happy to provide advice on  what is required to run a supported
  mail relay.  Besides operations and bug fixing, such support should include
  consulting for system administrators (if not for users).   Hopefully,  some
  suitable organization will be found to provide this service.


  * Ken King, BITNET Board of Trustees, is Named EDUCOM President

  The following is taken from an EDUCOM press release:

  Princeton,  New  Jersey--July 2,  1987:  The  EDUCOM Board of  Trustees has
  announced the appointment of Dr.  Kenneth M.  King as president,  effective
  September 15, 1987.  Currently vice provost for computer systems at Cornell
  University,  King  has a  distinguished career  of over  30 years  in major
  leadership positions  in university computing  services.   He  will replace
  Michael M.  Roberts,  named acting president last November while serving on
  leave from Stanford University as EDUCOM's vice president for networking.

  In announcing King's appointment, Douglas E.  Van Houweling,  vice chair of
  EDUCOM's  Board and  chairman of  the  EDUCOM Council,   cited King's  long
1

                                                                       Page 5


  experience in  both private  and public  higher education  across the  full
  range of programs from community colleges to graduate research universities
  as  providing  an exceptional  background  for  the presidency  of  EDUCOM.
  "Ken's record of innovation and service to information technology in higher
  education,  his demonstrated leadership ability,  and his clear vision make
  him the ideal president for EDUCOM."

  Currently the  chairman-elect of the EDUCOM  Council,  King has  twice been
  elected to  the EDUCOM Board  of Trustees,   from 1974-1976 and  again from
  1984-1987,  where he has served on both the executive and finance committee
  and  the  networking  committee.    In  addition,   he  represents  Cornell
  University on EDUCOM's Networking and Telecommunications Task Force.  He is
  also on the  Board of Trustees of  NYSERnet,  the New York  State Education
  Research Network, and of BITNET, Inc. He was recently named by the National
  Academy of Sciences to a committee on improving research productivity.

  At  Cornell  University  since 1980,   King's  leadership  has  encompassed
  microcomputing, networking,  and supercomputing.   In microcomputing he has
  initiated work  with several major companies  to infuse computing  into the
  curriculum, and he represents Cornell to the Interuniversity Consortium for
  Educational Computing, based at Carnegie Mellon University.

  In networking King has directed the  design and implementation of Cornell's
  campus-wide network as  well as its participating in  BITNET,  NSFNET,  and
  NYSERnet.   In supercomputing  he is one of the  principal investigators of
  the Cornell National Supercomputing Center project, one of five university-
  based   supercomputing  centers   established  by   the  National   Science
  Foundation.

  Prior to  joining Cornell University,   King spent  nine years at  the City
  University of  New York,  where his  last position was vice  chancellor for
  university systems.   On loan from CUNY,  he spent two years as director of
  the office of computer plans and controls and deputy director of operations
  in the Office of the Mayor of New York City.   Prior to those positions, he
  served from 1962 until 1970 as director of the Columbia University Computer
  Center.

  King received his Ph.D.  in theoretical physics from Columbia University in
  1962 and his B.A.  in physics from Reed College in 1951.  He is a member of
  Phi Beta Kappa and Sigma Xi.

  In accepting  the position,   King said  he is  particularly interested  in
  harnessing the collective  energies of the EDUCOM  membership to facilitate
  technology transfer,   information exchange,   and the  solution of  common
  problems.    "This   is  an  exciting   and  challenging  time   with  many
  opportunities to dramatically improve the quality of instruction, research,
  and administrative  systems at  universities and  colleges.   I  love being
  involved.  I believe EDUCOM can make a significant different."
1

                                                                       Page 6


  EDUCOM, a nonprofit consortium of over 500 colleges and universities and 70
  corporate associates,   was founded  in 1964 to  promote effective  use and
  management of information technology.


  * Availability of the NAMES Files -- Updated

  The  following  files  will  remain available  on  NICSERVE@BITNIC  and  on
  LISTSERV@BITNIC without restriction.

                              XMAILER   NAMES
                              MAILER    NAMES

  The  BITNIC  will maintain  an  additional  list (called  NAME-REQ,   NAMES
  request)  to  allow one account  per site to  have access to  the following
  NAMES files:  BITONLY NAMES,  EARN NAMES,   and NETNORTH NAMES.   To add an
  account  to the  NAME-REQ list,   an appointed  BITNET representative  must
  submit the request to AKLOM@BITNIC.   If more  than one account per site is
  requested a  brief explanation  of the  reason for  the additional  account
  should accompany the request.

  If the account to  receive the file is already one  of the appointed BITNET
  representatives, then do not request the same account be added to the NAME-
  REQ list.

  Once  the account  has  been added  to  the NAME-REQ  list  (and the  owner
  notified), the owner can send a command to LISTSERV@BITNIC to subscribe for
  automatic file  distribution.   The AFD  function will then  distribute the
  NAMES files overnight whenever they are updated.   Presently,  users on the
  INFOREP,  TECHREP,  and BIRREP lists may send LISTSERV a command to receive
  the files automatically.   Or,  alternatively,  accounts with access to the
  files may issue the FUI command to receive File Update Information.  Rather
  than receive  the file itself,  the  subscriber receives a notice  that the
  file has been updated.

  --Judith Molka
    BITNET Information Center


  * Committees of the Board of Trustees

  The Board of Trustees have set up several userids at BITNIC to which BITNET
  users can send mail.


  BOARD-L@BITNIC -  composed of  the entire Board  of Trustees  (See NICSERVE
  file BOARD87 MEMBERS for the complete list)

  EANDF-C@BITNIC - Executive and Finance (Ira Fuchs,  Philip Long,  Ray Neff,
  Leland Williams)
1

                                                                       Page 7


  MEMBER-C@BITNIC -  Membership and Fees  (Ken King,  Leland  Williams,  John
  Young)

  NETUSE-C@BITNIC - Network Usage Policies Ben Klein, Philip Long)

  SERVE-C@BITNIC - BITNIC Services (Don Laird, Marty Solomon, Ira Fuchs)

  TECH-C@BITNIC - Technical Issues (Doug Bigelow, Butch Kemper, Ray Neff, Ben
  Klein)


   *************************************************************************
  * Bitnet User Statistics                                                  *
  ***************************************************************************

  By Henry Nussbacher                                            HANK@BARILVM

  2 Sep 1987 11:24:49

  1885 nodes polled
  21565 active BITNET users are logged onto 987 connected nodes
  19593 VM users on 459 nodes (Average: 42)
  162 UNIX users on 38 nodes (Average: 4)
  1810 VMS users on 490 nodes (Average: 3)

  Largest sites listed:

  Nodename  Count  Type
  --------  -----  ----
  CERNVM    550    VM
  HNOESA10  390    VM
  SLACVM    329    VM
  NUSVM     311    VM
  UKACRL    287    VM
  ...
  HWALHW50  061    VMS
  FINUHA    045    VMS
  FINABO    039    VMS
  ...
  JHUNIX    043    UNIX
  UHNIX2    031    UNIX
  WISDOM    018    UNIX

  Now assuming that each VM site has  10 server  machines (too few for CERNVM
  but way too many for sites like SFUVM and USUVM):

                           16975 total users
                           15003 VM users
                             162 Unix users
                            1810 VMS users
1

                                                                      Page 8


  - These numbers are biased to Europe since America is currently asleep.
  - 88% of all logged on users are VM users
  - The average is 3.7 users per VMS site
  - The average per VM site is 32 users

  So when we get right down to examining the numbers, the reasons why  Bitnet
  is "dominated" by VM  shops  is obvious.  Functionality is  driven by  user
  requests, and most users are on VM systems.


   *************************************************************************
  *  Best of the Big Flamage                                                *
  ***************************************************************************

  (Pulled from FUTURE-L and other lists.)

  I don't  see how  XXXXX can  seem so  outraged that  these files  have been
  pulled out from under him when he quotes  from an entry in the Bitnews file
  from 2 months ago.  While  I will admit that I do not like  the idea of not
  being able to get to these files either (I'm not the TECHREP here),  it WAS
  announced.  Furthermore,  the  removal of BITONLY/NETNORTH/ EARN  NAMES was
  announced last week,   and was put into  place at this time  because of the
  constant pressure from the EARN people who  insisted that they did not want
  their users to be able to get to these files.

  I will admit  I feel that Bitnic  has made a mistake  on restricting MAILER
  and XMAILER NAMES.  I do not personally  see the need to restrict those two
  files,  mostly because they  are not very large,  and I  don't think people
  abuse  their access  to them.   And maybe  they should  have announced  the
  restriction again,  and  they did not mention  these two files in  the last
  mail they did send.   However,  I feel that they have erred  on the side of
  cautiousness. Everyone complains that there is too much traffic, that users
  ask for  files that tie  up the network and  they don't need,   anyway.  If
  anyone felt this strongly  about the need for these files,   why wasn't the
  discussion brought up in June,  when the  article was posted in Bitnews?  I
  think one major improvement  in BITNIC in the past few  months has been the
  increased amount of information placed in the Bitnews files.  If you're not
  reading it, then don't blame Bitnic.

  Personally, I do not like the fact that there is only one TECHREP per node.
  In the past, this only meant that you could not get mail for TECHREPs. Now,
  it means alot  more.  Rather than waste  time flaming about this  now,  why
  don't we make this (and the restricted  access of these files)  a topic for
  discussion in Chicago, at the preShare meeting.

  ***************************************************************************

  Does the NIC  really have too much to  do?  Or did EDUCOM sell  the Board a
  bill of goods.  From the little experience I have with EDUCOM the latter is
1

                                                                       Page 9


  true.  They are  a bunch of salespeople with no  technical abilities.   All
  they do  from my  experience is to  negotiate volume  discounts on  PCs and
  terminals for schools too small to do it on their own.

  ***************************************************************************

  Yes,  the  NIC,  before it  shut down  INFO@BITNIC was getting  hundreds of
  requests from people, from 'Is Oshkosh U connected', 'I am looking for Prof
  Wombat a famous physicist.    How can I find him?',  'My  Mail program just
  broke and no one at this site knows how  to fix it.   Can you help?' Not to
  mention the  hundreds of nodes  and lists  that were constantly  sending in
  requests for changes or modifications.   And then don't forget everyone and
  their grandmother who felt their idea was the right way to go and therefore
  "suggested" it  to the  NIC.   When asked  if they would  have the  time to
  codeup their idea that would take 1-2  months,  most people said they don't
  have the time or commitment from management.  And so it went.

  So yes, on one hand the NIC was very overloaded.   And you are not entirely
  correct about them being salespeople.   EDUCOM  was started as a consortium
  to manage EDUNET (remember that one?).    EDUNET was a logical network that
  used Telenet  as its  access medium.   If  you were on  the east  coast and
  needed some computer service  on the west coast,  then you  went to Edunet.
  Here it is  important to note that  EDUCOM was not responsible  for traffic
  management in  Telenet or  for writing access  programs to  Telenet.   They
  merely "arranged"  all the loose  ends for you.    When Bitnet got  off the
  ground,  EDUCOM  was no where  near it.   When  IBM came across  with their
  multimillion dollar  grant to set  up a NIC,   it was IBM  that recommended
  EDUCOM.   EDUCOM,  of course,  thought it was a great idea.   I don't think
  they realized what it was to run a Network Information Center.

  ***************************************************************************

  Even if the restriction is a good thing,  the way it was implemented showed
  a total insensitivity to those who might have automated processes. One does
  not substitite bad  data for good data  because it is assumed  a human will
  look at the contents of a names file. This is another example of the manual
  mode mindset the nic seems to have.

  I have just converted  my software to use the NETSERV  support out of EARN.
  While not  perfect,  at  least they understand  about automation  and table
  consistancy.

  ***************************************************************************

  As you can see we are approaching exactly what the problem is.   The people
  in EARN who manage  the network are also the ones who  write the code (Burt
  Pasch, Udo Mayer, Peter Castor, Dominick Pinse, Stribilt, etc.).  A network
  is not a static  item.   You can't expect a menu  of 'network functions' to
  work for 2  years.   That is why  when something breaks,  any  of the above
1

                                                                      Page 10


  mentioned people can go  into the 3000 line Rexx or  Pascal program and fix
  it.  The staff at Bitnic is not designed for that.

  ***************************************************************************

  And  this gives  them  the right  to  do  it?   As  long  as they  announce
  something, they can do it?

  ***************************************************************************

  With enough notice, even WISCVM can say they are shutting down and have the
  total right to do it if that is what they wish.

  ***************************************************************************

  Clearly,  the level of service BITNET provides is a joke.  The state of the
  net and the NIC  are pathetic.  The Board's concept of  service seems to be
  non-existant.

  ***************************************************************************

  I suggest you start comparing NIC services (Csnet, Arpanet and Bitnet)  and
  present a synposis to  this forum in a week or two.   While  you are at it,
  compare manpower  at each site and  total operating budget.   You  might be
  suprised at your own results.

  And if  that is all the  Contract with BITNET  calls for then the  Board is
  also lacking  in techinical  competence which shows  in their  inability to
  contract for anything meaningful.

  ***************************************************************************

  They contracted for what they could receive in terms of their budget.  With
  a larger budget, they could have contracted for more,  but people said they
  didn't want to pay more.  So they contracted for the bare minimum.

  ***************************************************************************

  If the reason for  restricting files is to cut down  on network traffic....
  THEN QUIT SIGNING UP NEW MEMBERS you idiots!  100-200 new nodes per quarter
  for a network that can't handle the traffic it has is stupid.

  ***************************************************************************

  By adding more nodes,   EDUCOM pulls in more money and  hopefully next year
  the BoD  will have  enough of a  budget to hire  more technical  people for
  BITNIC.   A major problem is finding qualified people in the Princeton,  NJ
  area.  All of them are taken already by Princeton and JVCC.

  ***************************************************************************
1

                                                                      Page 11


  In fact  those who  are presently  members should  begin to  complain about
  making BITNET a closed membership and start  forcing people to pay for what
  they get now.  Granted,  the old addage,  you get what you pay for is true.
  Nobody pays for BITNET so you get lousy service.

  ***************************************************************************


  People pay but just too little.   So why  not start a revolution to hike up
  sites membership cost to BITNET?

  ***************************************************************************

  The idea of starting ANOTHER network is  absurd.   Even if it was free like
  BITNET  used to  be  (which  is unlikely),   the  committment  in time  and
  resources required to connect and maintain gateways to other networks would
  prohibit most universities from joining.   We  have to live with BITNET and
  do whatever  we can  to improve  it.   I  think you  are wasting  your time
  waiting for  BITNIC/EDUCOM to provide  any technical support.    BITNET has
  always been  and most likely will  always be a "volunteer  driven" network.
  We're just running on momentum right now.

  ***************************************************************************

  In many  ways,  I  think that  the problem with  the NIC is  not  that they
  provide *bad*  service, but  they try  to do  too much.   On their  budget,
  they  can't compete with SRI or the ARPA NIC.

  What do I propose to do about this? Ok, how about this -- let's concentrate
  on doing  a FEW  things correctly and  completely and  not worry  about the
  frills for a while. The few things I consider important are:

  1. Timely,  ACCURATE node  listings and  updates.  This  is paramount  in a
  RSCS-style  network.   We  can't  afford  to  spend  time  fixing  boo-boos
  created because someone didn't have their  mind  on what they were doing or
  was working on another project.

  2.  Availablilty of informational documents  such as RFC's, Bit News files,
  information, etc. on an AUTOMATED  basis using the BEST tools possible.   I
  don't care if it wasn't invented there --  if it's the right tool,  use it.
  This business  of  not  having  peered lists  OR  allowing  off-site owners
  for lists is just plain absurd.

  3. Facilitating  access to useful  network tools  in a STANDARD  way.  Eric
  Thomas'  LISTSERV  supplies  all  the  functionality  of  BITSERV  NICSERV,
  NETSERV,   and   most of  the  functions   of  DATABASE in   a  consistent,
  straightforward fashion.  One  thing to learn,   and it's run  at dozens of
  sites, and it *works* ALL the time.
1

                                                                      Page 12


  Things I think the NIC has NO business doing:

  1.  User  Support. No  way,  no  if's ands  or  buts.   That's the  job  of
  individual sites or  mailing lists for  specialized  topics like XMAILER or
  MAILBOOK.  Finding individuals  should be up to the individual  user or the
  postmaster/designate/info-rep/whoever the   hell  is  in charge   of BITNET
  there,  not the NIC.  Connectivity questions and gateways to other networks
  are within the NIC  responsibility under section 1, above, but no further.

  2. Projects like  GRAND or DATABASE.  Research like that  is better done by
  universities.  GRAND   is a failure  -  let's  stop beating a   dead horse.
  DATABASE....well,  maybe.   It's  too complicated to  really  use remotely,
  it's  slow,    and  LISTSERV  provides   everything  except   the  indexing
  features, which could be remedied fairly quickly.

  3. Software  development.  Better  to commission people  at other  sites or
  accept volunteer  services and  programs  than  spend time  on development.
  It's cheaper,   and  it doesn't detract  from their  primary  mission which
  should be to coordinate the net.

  ***************************************************************************

  And I  remind everyone  that the  only technical  person at  Bitnic is  the
  person who maintains their machine and servers.   THEY ARE NOT PAID TO BE A
  TECHNICAL SUPPORT CENTER.

  I believe  that this  is EXACTLY  the problem  that myself  and others  are
  complaining about. BITNIC is a bunch of sales people, not technical people.

  They are NOT paid to be technical.

  That single fact is the most significant difference between BITNIC, SRI-NIC
  and CSnet's CIC, including the budget differences and staffing differences,
  which go with the contract.

  I believe that  the Board should have  contracted with EDUCOM to  provide a
  "Bitnet Sales Office" (BITSO).  The Board  acted like they wanted something
  for nothing.  They couldn't (wouldn't)  pay  for a Technical operation,  so
  they bought a non-technical operation and gave it a technical name,  hoping
  no one would  know the difference.  (CSnet  has the CIC -  Coordination and
  Information Center.)

  I still  think that the  Board rendered  an incompetent decision  when they
  opted for  a sales force instead  of a technical support  facility,  budget
  restrictions or not.  I believe that  having NO BITNIC would be preferrable
  to the present "non-techinical" BITNIC.  Take the money paid for BITNIC and
  provide  contracts  to Computing  facilites  on  the  net to  support  some
  particular piece of software or provide some particular server.
1

                                                                      Page 13


  Let's face it. Networks are not CHEAP, and they are getting more expensive,
  not  less!  High  speed communications  cost more  than low  speed.   As  I
  remarked once  before on of  these lists BITNET  is suffering from  its own
  success.  It has too many new nodes WHO  WANT TO USE THE NET.  If you could
  get people to join, but not use the net, then you might have a chance.  But
  BITNET  is selling  capacity and  capabilities  it doesn't  have and  can't
  provide.  New nodes need hand holding until  they figure out how to use the
  net and then they generate TRAFFIC because they CAN use the net!

  Remember the New York Phone Crisis of a  few years back (mid 60's)?  One of
  the  prime causes  was traffic  increased  beyond the  capabilities of  the
  physical plant to handle it.  Data communications traffic was just becoming
  a reality.   Ever wonder why 3 minutes  is the standard billing unit?  That
  was the average call duration for  many years.  Dial-up modems changed that
  radically!   The "Great Society" put a lot of money into the ghettos in NYC
  and people bought phones with that money and USED THEM.  Usage went through
  the roof and Bell had to put in  massive amounts of new equipment and cable
  to handle the loads.


   *************************************************************************
  * Commentary on WISCVM                                                    *
  ***************************************************************************

  (Pulled from LIAISON and other lists.)

  Based on evidence that  I will not describe here,  I  think there are many,
  many private BITNET  Internet gateways currently in operation.  They are
  probably kept  private due  to fears  about being  swamped,  and  having to
  support it, and answer complaints.

  So,  what to do?    I would like to see all sites  with private gateways go
  public at the same time.  This effectively implements most of the "regional
  gateways"  proposal that's  been suggested  a  number of  times.   Since  I
  somehow don't  think this  will happen  (officially),  then  what?   BITNIC
  should work  hard on convincing  DoD to let them  run a gateway.    For the
  millions of dollars a year that EduCom  is getting from BITNET sites,  they
  should work on this.   Any site with  both BITNET and Internet nodes should
  work on building their own gateway.

  ***************************************************************************

  I think that this entire discussion, while nice, should be dropped squarely
  in the lap of BITNIC. The necessary answers and decisions are of necessity,
  political.   (Certain individuals at NSF have already advised sites against
  providing such a gateway for a  variety of reasons.)   Questions of Funding
  support,  DoD  approvals,  and the  like are clearly  in the domain  of the
  Executive Committee  (or whatever its name  is these days).  EDUCOM  as the
  action  arm  of  the  Executive Committee  should  provide  "competent  and
  authoratative guidance" to the Executive Committee.
1

                                                                      Page 14


  I  think those  of  us who  can  view  things from  more  than one  network
  perspective must agreee - it's time  for BITNIC and the Executive Committee
  to provide a reason to continue paying dues.

  ***************************************************************************

  I guess I don't see that BITNIC has much to do with this.   They are simply
  hired by the  BITNET corporation and its  Board of Directors  (eg.   BOARD-
  L@BITNIC,  see  file BOARD87 MEMBERS  on NICSERVE)   to do a  specific job.
  (Just as  I assume the  SRI-NIC is hired  by DoD but  BITNIC may not  get a
  defense sized budget!).

  Therefore,  if we feel  it is important for BITNET to  have public Internet
  gateways,  then we should  let the board know!   Only they  can set policy,
  budgets, etc.   Only they can decide if the BITNIC machine has the capacity
  to handle a gateway, etc.  Whether there should be several gateways, etc.

  Likewise, if the Internet people feel a gateway is important to them,  they
  should be working with their administrations (eg. for ARPAnet, CSNET, etc.)
  to make sure it happens.

  ***************************************************************************

  BITNET is now faced with a sink or swim situation.  BITNET must either come
  to grips with the  need for a "professional solution" to  the gateway mess,
  or face being isolated and ostricised as a  joke - an example of how NOT to
  build a network.  It's fine to sell a product to lots of people, but if you
  can't provide that product, they're going to demand their money back.   And
  EDUCOM had best realize that their reputation  is on the line as well.   If
  BITNET fails, EDUCOM fails.

  You may think I am being overly dramatic. That we can patch things together
  for a while. That's true... for a while, as long as EDUCOM quits signing up
  new members. 100-200 sites per quarter!!!  That has been the growth rate of
  BITNET in the past year!

  ***************************************************************************

  Again, it is US who decide that BITNIC should sign up members for BITNET by
  electing  and talking  to  the Board  of  Directors.   As  I  see it,   the
  institutions which make up BITNET are  like the stockholders here,  and the
  OFFICIAL representatives  of the institution  convey their wishes  to their
  board.

  ***************************************************************************

  BITNET must  face up  to the fact  that there  are other,   more functional
  solutions out there for any non IBM site. UUNET is just getting started and
  will provide a  much preferred solution for any UNIX(tm)   site.  You still
1

                                                                      Page 15


  have to  pay,  just as you  do with BITNET,   so the difference will  be on
  service.    Especially on  the  quality of  that  service.  The  artificial
  constraints posed  upon networking  by IBM Remote  Job Entry  Protocols are
  rediculous in this day and age.  The  speed and topology of the network are
  also rediculous.  When the NSF is talking about linking facilities together
  at 56 to 1.5meg baud rates, 9600 baud is pathetic.

  ***************************************************************************

  There is  no limit  in the  protocol to  9600 bps!    That has  been chosen
  because  of  costs and  its  general  availability  all over  the  country.
  Obviously the IBM RJE protocols are  not meant to compete side-by-side with
  TCP/IP.   The RJE  protocols are for information movement ---  there is not
  TELNET for  example.   But  until recently,   the RJE  protocols offered  a
  compromise between function,  reliability and cost  (eg.  UUCP may be lower
  cost using  dial-up demand asynchronous  lines but  the capacity is  not as
  great).

  ***************************************************************************

  Now that  IBM has entered  the TCP/IP market place,   maybe it is  time for
  BITNET to become an INTERNET member.  You will be able to buy your hardware
  and  software from  IBM and  as a  Federal  contractor,  IBM  has a  vested
  interest in making their TCP/IP products work.

  Again, this situation is clearly one of major proportions and is clearly up
  to the Executive Committee to ask  for,  adopt and implement solutions.   I
  realize that August in  Academia is just like in France  - Nobody's home...
  but somebody  better start making  phone calls  because there are  only 120
  days from Labor Day to December 31st.

  ***************************************************************************

  I agree  that the situation is  serious and it will  take a lot of  work to
  make a go of  it.   I agree that "real soon now" many  more sites will have
  their own gateways between BITNET and the Internet.   This is spurred on by
  more available  and affordable TCP/IP  interface hardware and  software and
  the emergence of NSFNET and the regional networks.

  I have often felt that we should have more than one gateway!  You have only
  to watch your adjacent node with the  gateway (WISCVM)  build up a queue of
  hundreds of  files in  a few  hours because the  link to  CUNYVM is  out to
  understand the heavy use on that gateway.

  However, I also feel there should be a small set of "official" or "default"
  gateways ---  a reliable  set run by  sites dedicated  to making  them work
  which can be used.    Actually,  maybe one "default" which can  be used for
  cases where the address must be hard coded in some way, then a few regional
  gateways (on various "spokes" of BITNET  from CUNYVM)  which could be coded
1

                                                                      Page 16


  into peoples MAILER software.   Of course, this assumes the situation as it
  is.    Domain naming  and the  implied  smarter networks  needed to  handle
  network-independent names will mean changes in the future.   And,  more and
  more sites will probably be providing their own gateways for their outgoing
  mail.   For this to work, we must "do things right" and be sure domains are
  properly registered, etc.  (Eg. see the DOMAINS GUIDE).

  I am sure the board appreciates our comments.  I hope they will stay 'tuned
  in' to the discussions  and keep us posted about what  options they see and
  what the plans  are by posting to the  appropriate official representatives
  of each institution in BITNET and the various public lists.

  ***************************************************************************

  *If* SRI  grants access  and *if* SRI  allows a  ".bitnet" domain  and *if*
  someone buys a vax and *if* that vax supports name serving

  *then*  the vax  can direct  SMTP mail  to more  than one  WISCNET site  on
  BITNET.   Now, instead of having to handle all that mail,  the vax only has
  to provide name service.   The only  houskeeping required:   Someone has to
  keep up a "host name table".  Certainly a manageable task.

  If we wanted to take this one step further, (flame-proof suit on)  we could
  customize each MAILER MTPLATE  to also know about the closest  of the above
  mentioned WISCNET sites.

  Doing both of  these would distribute that 5-10,000 message  load among all
  the participating WISCNET sites.

  ***************************************************************************

  There  is  a  committee  of  BITNET Board  members  who  are  charged  with
  evaluating technical issues,  and a LISTSERV list to help them define those
  issues in need of evaluation.

  Please send your ideas for an ARPAnet gateway to TECH-C for them to see.


           ************                ********
          **          *               **      *                **************
         * *          * ************ * *      *               **            *
        *  *          *            *   *      * ***********  * *            *
       *   *          *            *   *      *           * *  *            *
      *    ************            *   ********           *    **************
     *    *          *             *  *      *            *   *            *
    *    *          * ************** *      *             *  *            *
   *    *          * *            * *      * ************** *            *
  *    *          * *            * *      * *            * *            *
  **************** ************** ******** ************** **************
1

                                                                      Page 17


   *************************************************************************
  * The Poetry Server:  BIALIK@BRANDEIS                                     *
  ***************************************************************************

  BIALIK is the first BITNET server dedicated to the subject of... poetry.

  The three commands that BIALIK accepts are POEM,  INDEX,  and HELP.   These
  commands must be  sent as interactive messages  to the user BIALIK  at node
  BRANDEIS; mail and files are not accepted.  All commands and qualifiers may
  be abbreviated to three letters.


  ***** POEM (synonyms: GET, SENDME)

  Request a poem.   POEM alone, or POEM/DAY, gets you the Poem of the Day; if
  there is no poem for today, you get a randomly-selected poem from the past.
  POEM/RANDOM gets you  a randomly-selected poem.   POEM   gets you a
  specific poem.   The number for each poem is an encoding of the date it was
  slated as Poem of the Day:  for  example,  the command POEM 870520 gets you
  the poem from May 20, 1987.


  ***** INDEX (synonym: LIST)

  Request an index  to all available poems.   The index  displays the number,
  author,  title,   and first line of  every poem.   The  qualifiers /TITLES,
  /AUTHORS,  /DATES,  and  /FIRST_LINES allow you to select how  the index is
  sorted.  The default is /AUTHORS.


  ***** HELP (synonym: INFO)

  Request a copy of the help file.


  ***** Other qualifiers

  All three commands  can accept one further qualifier,   which specifies how
  the  requested file  is to  be sent.    The options  are /MAIL,   /NETDATA,
  /PRINTER, /PUNCH, and /VMSDUMP.  For the HELP and POEM commands the default
  is /MAIL; for the INDEX command the default is /PRINTER.  The help and poem
  files contain  no lines longer  than 80 characters,   but the lines  in the
  index files  are up to  130 characters long and  will be wrapped  around if
  sent using /MAIL or /PUNCH.


  Examples:
             POEM 870520/VMSDUMP
             POEM/PRINTER 870520
             IND/FIR/NET
1

                                                                      Page 18


  Other:

  Chaim Nachman Bialik (1873-1934)  is said to be the greatest Hebrew poet of
  modern times.

  Questions, comments, and suggestions may be sent by mail to username LAV at
  node BRANDEIS.


   *************************************************************************
  * A New Name Server:  WHOIS@UKCC                                          *
  ***************************************************************************

  from Marc Rhorer                                                IAF101@UKCC

  Most administrative  people at University of  Kentucky and many  others are
  listed in the database of the name server WHOIS@UKCC.    It has proven very
  useful for  offices at UKCC  and may be useful  for others searching  for a
  particular official's Userid.

  Valid commands are:


  HELP
  Sends a list of valid commands.


  FIND 
  Locate the userid associated with a name, or vice-versa.

       For example:

       VM:  TELL WHOIS AT UKCC FIND Marc A. Rhorer
       VMS: SEND WHOIS@UKCC FIND Marc A. Rhorer

       The response would arrive in a message format, like so:

       $906@UKPR   Marc A. Rhorer - Office of International Affairs
       CCSMR@CCOL  Marc A. Rhorer - Chancellor's Office
       IAF101@UKCC Marc A. Rhorer - International Affairs


  GUESS
  Locate the userid associated with a name,  or vice versa,  using your "best
  guess" of the spelling.

       For example:

       VM:  TELL WHOIS AT UKCC GUESS Marc Rhorer
       VMS: SEND WHOIS@UKCC GUESS Marc Rhorer
1

                                                                      Page 19


       The response would arrive in a message format, like so:

       $906@UKPR   Marc A. Rhorer - Office of International Affairs
       CCSMR@CCOL  Marc A. Rhorer - Chancellor's Office (CCS)
       IAF101@UKCC Marc A. Rhorer - International Affairs  (disc.)
       ANT346@UKCC Mary Lucas Powell  (not on)
       SYSDATA@UKC Mary Ellis  (disc.)
       UKA011@UKCC Mary Kelly  (not on)
       MMARX@UKCC  Marty Marx  (not on)
       AEN008@UKAG Mark Fiedeldey
       AGR003@UKAG Mark Dahmer


  Note that both the  FIND and GUESS commands inform you  about the status of
  the user.   For example, "disc." tells you a user is in a disconnect state,
  "not on" is self-explanatory.


   *************************************************************************
  * Feedback                                                                *
  ***************************************************************************

  Date:     Tue, 04 Aug 87  14:15 EST
  From:     SEWALL@UCONNVM
  Subject:  NetMonth
  To:       BITLIB@YALEVM

  Re: your "Day in Bitnet: The Game"  Boy! have I discovered why "you have to
  figure out how to send mail to UUCP"  is a -15 bummer.   Getting to UUCP is
  easy,   there  are  many doors  (PSUVAX1,   harvard.arpa,   seismo.CSS.GOV,
  ucbvax.berkley.edu, uxc.cso.uiuc.edu, goodness knows what else).   The real
  trick is  finding a UUCP  mailer that knows the  path to the  addressee you
  want to reach.    Even some paths offered  up by the interactive  server at
  PSUVAX1 return: "Host Unknown" from that very site!

  No doubt there are sound reasons for modifying host tables.   If you lookup
  how  to   address  mail   to  dec.com  in   GATEWAYS  HELPNET,    it  says:
  user%domain.DEC gets translated to user%node.DEC@DECWRL.ARPA, and indeed it
  does.    The problem  is SMTP  at WISCVM  then sends  it back  to you  with
  "DECWRL.ARPA Host Unknown"  AND it's right!   The lastest  arpa host tables
  have no decwrl.

  (and today's answer is: user%node.DEC@DECWRL.DEC.COM)


  **********        ************      *****        *********        *********
  *        **********          *      *   *        *       **********       *
  *        *        *          ********   *        *       *        *       *
  ***************************************************************************
1

                                                                      Page 20


  Date:    08/05/87  18.01.24 GMT+1
  From:    
  To:      
  Subject: The Death of Simtel20

  Michael Dahlinger
  0049-6151-16-3016
  Institut fuer Kernphysik
  Schlossgartenstr.9
  D-6100 Darmstadt Germany

  I just read in Netmonth.jul87 (which I liked very much)  why my requests to
  ARCHIVE-REQUEST@SIMTEL20 are no longer responded.  It just disappeared!!

  For me  this is a great   pity,  because I used  it as a source  for public
  domain software for our PC's at the institute often.

  What now??

  The software stored under PC-BLUE etc. is too useful to disappear just like
  this. I would like very, very much to have access (perhaps via  a LISTSERV)
  also in the future.

  So I would like to encourage you to find a solution soon.

  ***************************************************************************

  Date:     Thu,  6-AUG-1987 12:30 EST
  From:     Kevin Cole 
  Subject:  NetMonth printing for VAX
  To:       BITLIB@YALEVM

  Why re-invent the wheel?

  I suspect most VAX sites receiving NetMonth of running JNET software.  This
  means that if NetMonth is sent out to those sites as a PRINT file,  all the
  user has to do when (s)he receives  it is add the qualifier /FORTRAN.   The
  following example illustrates:


          $ RECE
          Files to be received for KJCOLE
          Filename                From            Node            Records
          NETMONTH.1987JUL;1      BITLIB          YALEVM          1234
          BITNET.SERVERS;1        BITLIB          YALEVM          4321
          RECEIVE> REC NETMONTH.1987/FORTRAN


  However,  Ed McGuire of Grinnel College points  out that this only works if
1

                                                                      Page 21


  the file is type PRINT:   "If it shows up type PUNCH (as these things often
  do) you can't RECEIVE/FORTRAN.   I don't know whether to point my finger at
  the source of the file and say `nyah nyah,  punch cards don't have carriage
  control' or  at Jnet and  say `this is  an imperfect  world,  let me  do it
  anyway.'"

  Last but  not least,   the method  I use  is a  utility distributed  on the
  network called FILE.   FILE allows a user to set any attribute of a file to
  anything he or she wants.  If your site has it, you just say:

          $ FILE/ATTRIBUTE=(FORTRAN,NOIMPLIED) NETMONTH.1987JUL

  and it's done.  Hope this is useful to someone out there.

  Note from the Editor:    This was just one of many  helpful suggestions for
  converting NetMonth files in order to print them from VAXen.

  ***************************************************************************

  Date: 6 August 1987, 11:53:25 EDT
  From: Bruce ZZTong  
  To:   Chris Condon  

  Congratulations on a  year well done.   Looking forward to  the next action
  packed  volume.    Netmonth has  proved  itself  as  a priceless  tool  for
  increasing network  awareness at this node,   and undoubtably at  nodes all
  across Bitnet.  Keep up the good work.

  ***************************************************************************

  Date:     Tue, 18 Aug 87 14:02:16 +0200
  From:     Alain FONTAINE (Postmaster - NAD)" 
  Subject:  LNAME...
  To:       "The glorious Netmonth editorial board." 

  Hello.

  Thank you   for including information  about  LNAME  in the july   issue of
  Netmonth (received today  - would it  be  possible to have it  *printed* at
  yale and  sent by  *surface*  mail to Belgium?   maybe it  would  be faster
  :-)).

  I should  have  sent some  words of  introduction,  because  the  help file
  alone looks quite hermetic.   Well,  I  did not realize that you were going
  to  include  it   entirely...   Here  is   an  attempt  at   such  a  short
  introduction.   Maybe  it would  be wise   to include  it in  a forthcoming
  issue.
1

                                                                      Page 22


  Why would you like to get the LNAME utility?
  --------------------------------------------

  The  help  file  for  LNAME  has  been  published  in  the  July  issue  of
  Netmonth.  Such reference information,  invaluable   when one does have and
  use some product,  tends to be  somewhat  hermetic to the newcomer.  So you
  will find here a little introduction.

  Compared to  the  leading  brand,  LNAME removes  one  big  restriction and
  brings quite a few improvements.

  If    you     communicate    with    people    (or     servers)     outside
  BITNET/EARN/NETNORTH,   you need   to  use network  addresses  (userid  and
  node,  the  latter beeing often replaced   by a 'domain')  whose  parts are
  longer than  eigth characters,  and  may  include lower case  letters.  The
  standard command NAMES  does  not allow you  to do that;     that's the big
  restriction removed in LNAME.

  The improvements  can be  found in  detail by studying the   help file.  To
  summarize, I would  say that the biggest improvement is  that the layout of
  the screen is user definable (using screen  definition files - you may have
  lots of  them).   Since the  name of the file   to be viewed/edited  may be
  specified when  calling LNAME,  you may  use it as tool  to manage any kind
  of   small    databases   amenable   to   the    'NAMES'   format.    Other
  improvements include  the possibility to define  a multipage display  for a
  single entry,   the production of   compacted files,  a  powerfull 'SEARCH'
  command, and more...

  The thing is fully maintained, and available  from me.  I don't put it on a
  server,   since  it is  regularly updated,   and  I don't want   to receive
  comments and complaints based on older versions.

  The acknowledgement section:    LNAME is an offspring of  the NAME utility,
  available from  NYSHARE  at  WEIZMANN.  The original  idea  of  a definable
  screen is theirs.


   *************************************************************************
  * NetMonth Policies                                                       *
  ***************************************************************************

  * Subscribing to NetMonth and BITNET SERVERS:

  VM users can be added to the mailing list by issuing the following command:

      TELL LISTSERV AT MARIST SUBSCRIBE NETMONTH Your_full_name
1

                                                                      Page 23


  VAX/VMS users can subscribe in a similar way:

      SEND LISTSERV@MARIST SUBSCRIBE NETMONTH Your_full_name

  If you cannot send messages in this way, you can send the following command
  as the first line of a mail file to LISTSERV@MARIST:

      SUBSCRIBE NETMONTH Your_full_name

  Arpanet users may use this method, but must address the mail to:

      LISTSERV%MARIST.BITNET@WISCVM.WISC.EDU

  A subscriber  can delete  him/herself  from  the mailing  list  by  sending
  LISTSERV@MARIST the UNSUBSCRIBE NETMONTH command.

  * Letters to the Editor:  If you have questions  or  comments  about BITNET
  or  NetMonth  that  you  would  like  printed  here,  mail  your l etter to
  BITLIB@YALEVM.  Make  sure that you  specify  in  the "Subject:"  header or
  somewhere in the letter that it is for the  NetMonth  letters  column. This
  doesn't mean that your letter will be printed, but it helps.

  * Article Submissions: The only requirements for NetMonth articles are that
  they be informative,  interesting, and  deal with  BITNET  services (or any
  other  good BITNET  related topics).  The  editor  will  inform  you of any
  changes to your writing and will submit them  for your  approval, deadlines
  permitting.  Send your articles to BITLIB@YALEVM.

  * Printing this file:  VM users can print this file by  first copying it to
  NETMONTH LISTING and  then printing  the new file.  This will  allow  page-
  breaks and other formatting to be understood by your printer.

  ---------------------------------------------------------------------------

  A publication of the Bitnet Services Library          "Because We're Here."